1. Technical Field
The present invention relates in general to the data processing field. More specifically, the present invention relates to the field of testing object oriented software.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices. Modem computer systems contain relatively complex software that the computer hardware executes in order for the computer system to perform its intended functions. As the complexity of computer software increases, the need to test computer software becomes more and more critical.
In the past, testing computer software required that a programmer write special-purpose test code that would perform the desired testing. For the purpose of clarity in the discussion below, the term xe2x80x9ctest codexe2x80x9d refers to software that is developed to test other software; the term xe2x80x9csoftware under testxe2x80x9d refers to software that is being tested by the test code; the term xe2x80x9ctest programmerxe2x80x9d refers to the programmer that programs the test code; and the term xe2x80x9capplication programmerxe2x80x9d refers to the programmer that programs the software under test. Note that the term xe2x80x9capplication programmerxe2x80x9d should not be construed to mean that the software under test can only be a software application; rather, the software under test can be any type of computer software, including applications, system software, or any other type of software. The term xe2x80x9capplication programmerxe2x80x9d is simply a label used to identify a person that develops software under test, regardless of what type of software under test is being developed. In the prior art, when an application programmer generates new software that needs to be tested, a test programmer who is familiar with software testing techniques generates special test code that performs the desired testing on the software under test to assure the software under test functions properly. This test code is typically special-purpose code, generated for testing specific software on a particular platform. As the diagnostic requirements change, the test programmer generally writes new code for each new requirement, and deletes the code that pertains to tests that are no longer needed. An example of test code development may be illustrated by a simple example. When a new software application is initially developed, the various modules of the application may be developed separately, with each one being individually tested before integrating the various modules into a functioning application. A test programmer would generate test code that will provide the required diagnostics on each module. Once the various modules are integrated into a single application, the test programmer would provide a fully integrated diagnostic test to test the entire software application. The testing of the software in this stage is for the purpose of design and functional verification, and the test code will thus perform exhaustive diagnostics on all portions of the software under test to assure the integrity of its design. Once the design is verified, as the software under test is released for sale, the test software must evolve again to accommodate the more time-sensitive and less exhaustive diagnostics required in production screening and testing. The test programmer must then pare down the test code to perform the less exhaustive tests for production testing of the software under test.
The process of generating test code has been burdensome. Generally the test programmer starts from scratch, defining custom test code to match the specific requirements of the software under test and the platform running the software under test. As changes to the software under test are required, the programmer makes changes to the test code to accommodate those changes. When the project concludes, the test code generally cannot be reused on different software under test, such as a new software application, because the specific interface and test requirements are generally different enough to preclude porting the test code to new applications. As a result, test code to date has generally not been readily customizable and easily extendable to testing new software.
Another problem in testing software is the difference between developing a software application and testing the software application. Software is often tested in a language and environment that is different from those used to develop and maintain the software. As a result, many skills, tools, and paradigms from the development realm are not reusable in the testing realm, and vice versa. This is the reason that two different kinds of programmers must generally be used to develop and test software. Application programmers design and develop the software under test. Test programmers design, develop, and run the test applications on the software under test. The tools that test programmers use may be in a different language and may have nothing in common with the tools used by the application programmers to develop the software under test. This environment makes it difficult for an application programmer to test his or her application software, and requires instead that a separate person with a different set of skills be used to test application software.
Yet another problem in testing software is that test code is typically poorly documented, and the documentation that does exist, such as test plans, strategies, user""s guides, and the like, tends to become obsolete because the documentation is not scrupulously updated as the test code evolves over time. Thus, it is not uncommon for test code documentation to not accurately reflect the function of the test code.
As the complexity of computer software increases, the need for better mechanisms for software testing becomes more apparent and more acute. Without a mechanism that can be readily customized and extended to generate new software tests in a uniform manner, the ability to adequately test computer software in a cost-effective manner will be impaired.
According to the present invention, an apparatus and method for testing object oriented software includes a software test framework that includes one or more test drivers and one or more testcases for each test driver. Each testcase can also have multiple variations. A TestDriver abstract class and a Testcase class are defined. Each test driver is a created as an extension of the TestDriver class, and each testcase is created as an extension of the Testcase class, thereby promoting uniformity between different test drivers and between different test cases. When an instance of the TestDriver class is run, it instantiates its testcases, determines which variations of the testcases should be run, runs the variations, and reports the results. By providing the software test framework in the same programming environment in which the software under test is developed, the application programmer can program the needed tests without requiring the specialized skills of a test programmer.
The foregoing and other features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings.